Skip to content

Add migration support to the SSA client#480

Merged
metlos merged 3 commits intocodeready-toolchain:masterfrom
metlos:ssa-migration-only
Apr 30, 2025
Merged

Add migration support to the SSA client#480
metlos merged 3 commits intocodeready-toolchain:masterfrom
metlos:ssa-migration-only

Conversation

@metlos
Copy link
Contributor

@metlos metlos commented Apr 28, 2025

The migration from CSA (client-side-apply) to SSA is in the end needed (we first thought we could do without it), because the "dangling" update entries in the managed fields could prevent the automatic field removal in some future update (that could happen many operator versions later, as long as the object still survives from the times where our operators didn't use SSA for creating/updating objects in the cluster).

@codecov
Copy link

codecov bot commented Apr 28, 2025

Codecov Report

Attention: Patch coverage is 66.66667% with 15 lines in your changes missing coverage. Please review.

Project coverage is 78.73%. Comparing base (c883496) to head (c674232).
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
pkg/client/ssa_client.go 66.66% 11 Missing and 4 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #480      +/-   ##
==========================================
- Coverage   78.95%   78.73%   -0.23%     
==========================================
  Files          52       52              
  Lines        2604     2647      +43     
==========================================
+ Hits         2056     2084      +28     
- Misses        490      501      +11     
- Partials       58       62       +4     
Files with missing lines Coverage Δ
pkg/client/ssa_client.go 87.70% <66.66%> (-12.30%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@sonarqubecloud
Copy link

Copy link
Contributor

@MatousJobanek MatousJobanek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👍

// The user agent can be obtained from the REST config from which the client is constructed.
//
// The user agent in the REST config is usually empty, so there's no need to set it here either in that case.
NonSSAFieldOwner string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in your code in the previous PR, you originally had a code that was able to construct the owner name we should migrate from - couldn't we use that?
https://github.com/metlos/toolchain-common/blob/6ff87dfbb853a19475dff63b22a0e5a2f51300d9/pkg/client/ssa_client.go#L50-L62

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We technically don't need this because no code in the current codebase sets the field owner explicitly in the CRUD operations and therefore all the code uses the default field owner derived from the user agent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to have this option available though in case I missed something and we for example set the user agent of the kubernetes client to an explicit value somewhere in the code.

In that case, we'd need to set this to an explicit value, too.

Comment on lines +187 to +192
if len(oldFieldOwner) == 0 {
// this is how the kubernetes api server determines the default owner from the user agent
// The default user agent has the form of "name-of-binary/version information etc.".
// The owner is the first part of the UA unless explicitly specified in the request URI.
oldFieldOwner = strings.Split(rest.DefaultKubernetesUserAgent(), "/")[0]
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

related to my previous comment, do you think that we would need to se the owner name explicitly? Couldn't we rely on the default behavior only?

Copy link
Contributor Author

@metlos metlos Apr 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could, but the default behavior makes assumptions that I was not 100% sure we satisfy everywhere in the codebase, so I wanted to have an explicit option available for the case we find a place where the defaults would not be applicable.

The default behavior assumes that:

  1. There is no user agent set explicitly in the config of any kubernetes client.
  2. We don't explicitly set the field owner with any of the existing CRUD operations with the kubernetes clients.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no user agent set explicitly in the config of any kubernetes client.
We don't explicitly set the field owner with any of the existing CRUD operations with the kubernetes clients.

I'm not aware of any place that would change any of these explicitly, so everything should comply.

Anyway, thanks for the explanation. It's fine to keep it there if not required to be set explicitly by default (only as a backup solution for some corner-cases).

@metlos metlos merged commit 95cf792 into codeready-toolchain:master Apr 30, 2025
9 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants